Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Oracle Office Systems

The Oracle Office system is designed to provide office services such as messaging and scheduling. Oracle Office is a client/server application that uses the Oracle RDBMS system on the servers. The Oracle Office system also uses a replication method to duplicate data throughout the system.

The Oracle Office system consists of the following components:

  The Oracle Office client: the component that sits in the individual workstation.
  The Oracle Office server: the component that runs on the server.
  The Oracle RDBMS: the database used to maintain the data used by Oracle Office.
  SQL*Net: the communications link that eliminates the need for any specific network protocol.
  Other components: these include the gateway software, the Oracle Office Manager, and an API that lets you program your own interface to Oracle Office.

Oracle Office is a complex suite of components that can assist you in your day-to-day operations by providing general office services. In the scope of this book, I address only the Oracle Office server components and RDBMS.

System Characteristics

The Oracle Office system is designed to service many individual users simultaneously. Your office environment may consist of just a few or hundreds of clients accessing the same server. Because of this variety, the system appears very similar to the OLTP system in both characteristics and function. Some of these characteristics are listed here:

  Simultaneous access to data. Many users each access their messages, schedules, calendar, and directory services.
  Data is accessed with both reads and writes. Not only do users check messages, they continually produce new ones.
  The database tends to grow. As time passes, more and more data is saved in the system, creating a need for more space in the database.
  Large number of users. Although the number of users depends on your installation, typically, the entire corporation is connected to these types of services.
  Response-time constraints. As with the OLTP system, servicing online users requires that certain response times must be achieved. Response time can be a critical component of the system design.
  Continuous uptime. An office system may need to be in operation 24 hours per day, 7 days a week without any downtime. Special considerations must be made for fault-tolerant components or backup systems.

These characteristics may vary slightly based on your particular configuration and the number of users you service. Some components (such as the uptime requirement) can require additional hardware resources to provide additional fault tolerance.

Design and Tuning Hints

Because the system operates in a manner similar to that of a traditional OLTP system, many of the design and tuning parameters are similar to those of the OLTP system. The goals are to achieve good response times and a high level of fault tolerance.

Design

The layout for the office system is almost identical to that of the OLTP system except that you don’t have as much control over the contents of the database tables themselves. A minimal configuration should look something like this:


Element (# of Disks) Comments

System (1+) The system disk is used for the operating system, swap file (if applicable), user files, and Oracle binaries. Mirror this disk for additional fault tolerance.
Redo log (1+) You should have at least one log volume. This volume should be made up of at least two physical disks using RAID-1. By using only one log volume, performance degrades during archiving because the sequential nature of the log writes is disrupted.
Archive logs (1+) The number of disks needed for the archive log files is determined by the amount of data you have to archive. This data can be written to tape as necessary.
Data and index (1+) Because you always get concurrent access to disks with a disk array, it is not necessary to split the data and indexes into separate volumes. The number of disks you need for data and index is determined by the amount of random I/O your user community generates. If it is within your budget, I recommend mirroring the data and index files because of the uptime criterion usually associated with the office system.

Both the data files and the indexes should be striped over as many disk drives as necessary to achieve optimal I/O rates on those disks. From Chapter 14, “Advanced Disk I/O Concepts,” remember that you can only push a disk drive to a maximum random I/O rate.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.